1. Field of the Invention
The present invention relates to calendar management in a calendaring application and more particularly to handling repeating calendar events in a calendaring application.
2. Description of the Related Art
Calendaring systems have formed the core component of personal information management software and firmware applications for decades. Initially, a mere calendar display, modern calendaring systems provide scheduling and alarm functions in addition to full integration with contact management, time entry, billing and project management applications. The typical calendaring application minimally provides a mechanism for scheduling an event to occur on a certain date at a certain time. Generally, the event can be associated with a textual description of the event. More advanced implementations also permit the association of the scheduled event with a particular contact, a particular project, or both. Furthermore, most calendar applications provide functionality for setting an alarm prior to the occurrence of the event, as well as archival features.
Several software products include support for Calendaring & Scheduling (C&S). Known C&S products include Lotus Notes, Microsoft Outlook, and web-based products like Yahoo! Calendar. These products allow one to manage personal events including appointments and anniversaries. C&S products also typically allow one to manage shared events, referred to generally as meetings. Notably, many C&S products include the concept of repeating events. The creation of repeating events is generally straightforward. The user interface permits one to define the first instance of the repeating series and to specify how the series repeats. For example, an event might repeat weekly for five weeks or it might repeat monthly until Dec. 31, 2005. The definition of a repeating series often is referred to as a “recurrence rule”.
More specifically, an important feature of a calendaring system includes the ability to schedule a recurring event without requiring the end user to individually set an event on each recurring date. For example, where a meeting is to occur every week on a particular time over the course of several months, the end user can schedule the event as recurring every week at the particular time for the course of the several months. The calendaring system, in turn, can schedule each event in an automated fashion based upon the recurring information. Advantageously, the end user subsequently can modify any one of the recurring events, or the end user can apply a single modification to all of the recurring events responsive to which the calendaring system can apply the single modification to all of the recurring events in an automated fashion.
In recent years, computing has changed from a centralized model to a distributed model. Vast computer communications networks now connect select users across the enterprise. Leveraging the wide reach of the modern enterprise, calendaring systems can incorporate multiple users and the events scheduled by multiple users. In particular, “groupware” oriented calendaring systems can permit one user to view and schedule events of other, remotely positioned users. To further provide interoperability between different types of calendaring systems, entire specifications have been developed to accommodate the distributed and disparate nature of the calendaring world. RFC2445 entitled “The Internet Calendaring and Scheduling Core Object Specification (iCalendar)” represents one such effort.
Notably, distributed and interoperable calendaring systems, like their stand-alone progeny, support the establishment of recurring events without requiring the end user to set each individual recurring event manually. Yet, more recent calendaring implementations no longer simply automate the process of setting multiple events specified by as recurring in nature. Rather, to conserve storage space, recurring events can be stored as a single event described as recurring in nature. More particularly, in order to optimize for space, the storage model employed by advanced calendaring systems stores only the event data and the recurrence rule. The actual event instances can be calculated dynamically when a request is processed to retrieve events within a certain date range.
The user interface for editing repeating events typically is not straightforward in nature. Some C&S products allow one to select a repeating instance, place the repeating instance in edit mode, and apply changes to the repeating instance. A noted problem is that the user interface does not allow one to adequately express intent in editing a repeating instance. Examples include:                a) Are all instances of a repeating series to be edited, a subset of the instances, or just the selected instance?        b) When editing more than one instance, should each field for each instance be changed or should only selected fields be changed?        c) When changing the date or time of an event and saving changes to all instances, is it the intent to recreate the recurrence rule thereby undoing previous changes to single instances?        d) When editing events associated with workflows, how are participants to be notified of changes?        
Importantly, a modification to a recurring event can be applied universally, to single instances of the recurring event, to past instances of a recurring event, or to all future recurring events. As described in RFC2445, however, the modification of the recurring event can be applied internally to the recurring event. Specifically, the recurrence rule defined within the recurring event, itself, can include the modifications to the recurrence rule. Interpreting and applying a modification to a recurrence rule in the conventional model, however, can be difficult and problematic for the uninitiated. Accordingly, it would be preferable to incorporate a simplified system, method and apparatus for applying modifications to recurring events in a calendaring system.